Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0399/260

Internet Message Format | 1994-08-27 | 1.6 KB

Subject: Re: SHORTCUT.INF
Date: Thu, 2 Jun 1994 14:55:45 +0200 (MDT)
In-Reply-To: <[e-mail]> from "Ofir Gal" at Jun 2, 94 09:59:00 am
From: [e-mail] (Annius Groenink)
X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
 ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
 m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
Mime-Version: 1.0
Precedence: bulk


> 2. More importantly, what if a user defined key conflicts with your app.
> Say the user decides that Select All should be CTRL+L, but your app
> already uses CTRL+L for something else.

There a two options.  Either we bind a key to an action,  or an action
to a key.  As we cannot bind two actions to the same key,  clearly we
need the first one.  So the SHORTCUT.INF file would have entries like:

(application-group)(key)    ->    (action)


Now what an application does when it reads the file is:  first read
SHORTCUT.INF.  If you find the key,  and the application-group matches
you,  then perform the action on the RHS of the ->.  Otherwise,  scan
your private bindings.

So if a user decides that CTRL L is select all,  then CTRL L for that
other thing is no more valid.


This does require that while reading SHORTCUT.INF,  the application will
have to change the menu.  It should of course be possible to do this
efficiently.

--
Annius V. Groenink | E-mail: [e-mail]      |  Private & ZFC:
CWI, Kruislaan 413 | Room:   M233            |  P.O. Box 12079
1098 SJ Amsterdam  | Ext:    4077            |  NL 1100 AB Amsterdam
Netherland         | Phone:  [phone] |  Phone: [phone]